home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19960425-19960715 / 000357_news@columbia.edu _Wed Jul 3 18:22:21 1996.msg < prev    next >
Internet Message Format  |  2020-01-01  |  2KB
  1. Return-Path: news@columbia.edu
  2. Received: from apakabar.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id SAA20657 for <kermit.misc@watsun.cc.columbia.edu>; Wed, 3 Jul 1996 18:22:20 -0400 (EDT)
  3. Received: (from news@localhost) by apakabar.cc.columbia.edu (8.7.5/8.7.3) id SAA27840 for kermit.misc@watsun; Wed, 3 Jul 1996 18:22:19 -0400 (EDT)
  4. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  5. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  6. Newsgroups: comp.protocols.kermit.misc
  7. Subject: Re: file transfer
  8. Date: 3 Jul 1996 22:22:15 GMT
  9. Organization: Columbia University
  10. Lines: 27
  11. Message-ID: <4rerqn$r5u@apakabar.cc.columbia.edu>
  12. References: <omafxh7spj.fsf@tees.cs.ualberta.ca> <4rdvqf$g9n@apakabar.cc.columbia.edu> <omohlx58ee.fsf@tees.cs.ualberta.ca>
  13. NNTP-Posting-Host: watsun.cc.columbia.edu
  14.  
  15. In article <omohlx58ee.fsf@tees.cs.ualberta.ca>,
  16. Vladimir Alexiev  <vladimir@cs.ualberta.ca> wrote:
  17. : In article <4rdvqf$g9n@apakabar.cc.columbia.edu> fdc@watsun.cc.columbia.edu (Frank da Cruz) writes:
  18. : 
  19. : > A very common cause of errors when you are using long packets is buffer
  20. : > overruns
  21. : 
  22. : Frank, your diagnostic was very precise. I reduced the packet size from
  23. : 9000 to 4096, and now kermit can sustain that rate indefinitely long.
  24. : Maybe kermit's fallback strategy needs to be tuned up a bit? Why does it
  25. : have to fall from 9000 all the way down to 17, if it can sustain at 4096?
  26. : 
  27. So you were sending from C-Kermit to MS-DOS Kermit, so C-Kermit is the one
  28. who is shortening the packets.  I agree, it should settle to a value that
  29. is optimal, and usually it does better than what you have observed.  The
  30. algorithm is approximately this:
  31.  
  32.   Read a packet.
  33.   If there is an error, reduce the packet size by half, down to some minimum.
  34.   If there was not an error, increase it by 1/3, up to the negotiated max.
  35.  
  36. So after "bottoming out" at 17, it should have gone back up.  Why didn't it?
  37. I don't know.  It usually does.  I would need to see a packet log to give a
  38. better answer.  If you want to send me one (don't post it), feel free.  Send
  39. the one from C-Kermit, uuencoded.
  40.  
  41. - Frank